<html>
<head><meta charset="utf-8"><title>Next steps? · t-libs/wg-allocators · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/index.html">t-libs/wg-allocators</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html">Next steps?</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="186345111"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/186345111" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#186345111">(Jan 23 2020 at 00:02)</a>:</h4>
<p>After our first merge has landed (I assume it will get through the FCP), what do you think are the logical next steps? One possibility would be to merge alloc-wg step by step as far as possible (this excludes <code>Box</code>, <code>Vec</code> etc.), starting with the separation of <code>AllocRef</code> into <code>DeallocRef</code>, <code>AllocRef: DeallocRef</code>, and <code>ReallocRef: AllocRef</code>. Another option could be the associated error type. Both shouldn't change much, but It would be helpful to get feedback from the outside of this WG regarding both. <br>
If we want to experiment even more, <code>BuildAllocRef</code> could be interesting, but only paired with changing the signature to <code>self</code> instead of <code>&amp;mut self</code>.</p>
<p>Opinions?</p>



<a name="186346177"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/186346177" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#186346177">(Jan 23 2020 at 00:20)</a>:</h4>
<p>One step, not sure where it goes in the process, is to announce very loudly that this is moving into Nightly and for people to <em>please</em> try it. Be as weird as possible with it. Push the design to its absolute limits and see what breaks.</p>
<p>We don't want to have a lack of feedback on this one. Allocators are really going to have a lot of influence on Rust at least for this entire edition, if not forever.</p>



<a name="186346343"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/186346343" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#186346343">(Jan 23 2020 at 00:24)</a>:</h4>
<blockquote>
<p>not sure where it goes in the process</p>
</blockquote>
<p><a href="https://users.rust-lang.org/" target="_blank" title="https://users.rust-lang.org/">https://users.rust-lang.org/</a> is a must-have I guess. Also reddit is a suitable place IMO.</p>



<a name="186346581"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/186346581" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#186346581">(Jan 23 2020 at 00:28)</a>:</h4>
<p>i meant I'm not sure how soon to shout about it</p>



<a name="186346588"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/186346588" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#186346588">(Jan 23 2020 at 00:28)</a>:</h4>
<p>Ah</p>



<a name="186346756"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/186346756" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#186346756">(Jan 23 2020 at 00:31)</a>:</h4>
<p>I think we should first implement some things that differ strongly enough from the current implementation. I think <code>BuildAllocRef</code> is the biggest change so far and also needs most fine-tuning and testing.</p>
<p>Error handling is also a big point I think.</p>
<p>As soon as we can touch <code>Box</code>, <code>Vec</code>, etc., it becomes important again.</p>



<a name="186348200"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/186348200" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mike Hommey <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#186348200">(Jan 23 2020 at 00:59)</a>:</h4>
<p>It feels to me the shouting and the getting people to test could be done with the alloc-wg crate</p>



<a name="186350392"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/186350392" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#186350392">(Jan 23 2020 at 01:41)</a>:</h4>
<p>What about a hybrid approach? Pushing some things upstream first, make an announcement and link the alloc-wg crate for more features? I think if some features are merged into master, more people will test these out.</p>



<a name="186365906"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/186365906" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#186365906">(Jan 23 2020 at 08:00)</a>:</h4>
<p>Having it be in Nightly and "automatically available" is a big deal, worlds better than telling someone to try the alloc-wg crate.</p>
<p>Anyone, at any time, can go make some random crate with whatever insane ideas about allocation they want to cook up.</p>
<p>But, if you've put something into Nightly, there's at least like 3 or 4 other people in the world (maybe more?) who think it's a good enough idea to let the experimentation into the <em>official compiler</em>.</p>
<p>It's not the final step in the path at all, but it's a landmark that the wider public will easily recognize as being a significant point of progress for this project. That's good PR. That's a positive step towards fixing one of the biggest areas where Rust still lags behind C/C++.</p>
<p>There's such a thing as over selling it, but this is a pretty important step if you stop and think about it much.</p>



<a name="186370690"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/186370690" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#186370690">(Jan 23 2020 at 09:21)</a>:</h4>
<blockquote>
<p>Allocators are really going to have a lot of influence on Rust at least for this entire edition, if not forever.</p>
</blockquote>



<a name="186370697"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/186370697" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#186370697">(Jan 23 2020 at 09:21)</a>:</h4>
<p>Not disputing this, but what sort of influence do you have in mind?</p>



<a name="186780938"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/186780938" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#186780938">(Jan 28 2020 at 13:16)</a>:</h4>
<p>We did it, the first change has landed on master!</p>



<a name="189952000"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/189952000" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#189952000">(Mar 07 2020 at 01:55)</a>:</h4>
<p>I'm pretty excited about <a href="https://github.com/rust-lang/wg-allocators/issues/38" target="_blank" title="https://github.com/rust-lang/wg-allocators/issues/38">#38</a>, <a href="https://github.com/rust-lang/wg-allocators/issues/41" target="_blank" title="https://github.com/rust-lang/wg-allocators/issues/41">#41</a>, and <a href="https://github.com/rust-lang/wg-allocators/issues/42" target="_blank" title="https://github.com/rust-lang/wg-allocators/issues/42">#42</a>. I think all of them, but especially the formers, will greatly push <code>AllocRef</code> to the right direction.</p>



<a name="190412289"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/190412289" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#190412289">(Mar 12 2020 at 16:37)</a>:</h4>
<p><span class="user-mention" data-user-id="216785">@Tim Diekmann</span> I'm not going to be very responsive this week, I'm on holiday.</p>



<a name="190412685"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/190412685" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#190412685">(Mar 12 2020 at 16:40)</a>:</h4>
<p>No problem, enjoy it!</p>



<a name="190745690"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/190745690" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#190745690">(Mar 16 2020 at 16:21)</a>:</h4>
<p><span class="user-mention" data-user-id="143274">@Amanieu</span> Should I squash the commits in <a href="https://github.com/rust-lang/rust/issues/69889" target="_blank" title="https://github.com/rust-lang/rust/issues/69889">#69889</a>?</p>



<a name="190755671"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/190755671" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#190755671">(Mar 16 2020 at 17:32)</a>:</h4>
<p>I don't mind either way. I personally prefer keeping the commits clean (one for each major feature).</p>



<a name="190761242"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/190761242" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#190761242">(Mar 16 2020 at 18:17)</a>:</h4>
<p>Alright, will squash them once the CI passed</p>



<a name="190776885"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/190776885" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#190776885">(Mar 16 2020 at 20:38)</a>:</h4>
<p>Squashed and passed CI</p>



<a name="191053127"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/191053127" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#191053127">(Mar 18 2020 at 22:54)</a>:</h4>
<p>I think I have found a solution to solve the unsoundness of <a href="https://github.com/rust-lang/rust/issues/69889" target="_blank" title="https://github.com/rust-lang/rust/issues/69889">#69889</a> and it solves the performance regression. I will probably push the changes to <code>alloc-wg</code> tomorrow and make a new proposal.</p>



<a name="191096999"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/191096999" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Wodann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#191096999">(Mar 19 2020 at 10:56)</a>:</h4>
<p>Interested to see your fix <span aria-label="thumbs up" class="emoji emoji-1f44d" role="img" title="thumbs up">:thumbs_up:</span></p>



<a name="191346303"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/191346303" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#191346303">(Mar 21 2020 at 13:45)</a>:</h4>
<p>Due to private reasons I'm very busy currently. I'll come back to the issue as soon as I can!</p>



<a name="191347463"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/191347463" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#191347463">(Mar 21 2020 at 14:11)</a>:</h4>
<p>In short: There are two reasons, why <code>layout.size()</code> may be zero: <code>T</code> is zero-sized or we allocate zero <code>T</code>s. The former may be solved by adding <code>T</code> to <code>Layout</code> (<code>MemoryLayout&lt;T&gt;</code>?). Then we could add <code>&lt;T: ?Sized&gt;</code> to <code>alloc</code>/<code>dealloc</code> and <code>&lt;T&gt;</code> to <code>grow</code>/<code>shrink</code>. Checking for the size of <code>T</code> is then done at compile time again and I came up with a solution to have <code>size_of::&lt;MemoryLayout&lt;T: Sized&gt;&gt;() == 8</code> (64bit, only storing capacity) and  <code>size_of::&lt;MemoryLayout&lt;T: !Sized&gt;&gt;() == 16</code> bytes (storing size and align). The other case is, that we request a capacity for 0 <code>T</code>s. This could simply be forbidden, it doesn't even make sense.</p>
<p>Another issue I had was the parameters/return value of <code>grow</code>/<code>shrink</code> when passing <code>ReallocPlacement</code>. With another struct <code>MemoryBlock</code> or <code>Allocation</code> we could store the pointer (<code>Unique&lt;T&gt;</code>) and <code>MemoryLayout</code> in that struct. <code>alloc</code> returns <code>Result&lt;MemoryBlock, _&gt;</code>, <code>grow</code>/<code>shrink</code> takes <code>&amp;mut MemoryBlock</code> and returns <code>Result&lt;(), _&gt;</code> and dealloc consumes <code>MemoryBlock</code>. <code>MemoryBlock</code> would neither implement <code>Copy</code>, nor <code>Clone</code>.</p>
<p>With those adjustments the mentioned unsoundness would also dissappear as long as we change <code>into_box</code> to return <code>Box&lt;[MaybeUninit&lt;T&gt;]&gt;</code>. the boxed slice implementation must then adjust the length of the box and can call <code>assume_init</code>. It's fine to use the excess, as it is reserved for the <code>MemoryBlock</code> anyway and it is valid to pass a layout size between the size passed in <code>alloc</code> and the actual size.</p>



<a name="191348372"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/191348372" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#191348372">(Mar 21 2020 at 14:32)</a>:</h4>
<p>Regarding the size of <code>MemoryLayout&lt;T&gt;</code>: I want <code>size_of::&lt;MemoryLayout&lt;T&gt;&gt;() == size_of::&lt;Option&lt;MemoryLayout&lt;T&gt;&gt;&gt;()</code>. <code>T</code> may be a ZST, so we can't store <code>size</code> in <code>MemoryLayout&lt;T: Sized&gt;</code> but the capacity is non-null. For <code>MemoryLayout&lt;T: !Sized&gt;</code> the size also may be null, but the alignment is not null. In both cases, there is one value non-null allowing the option-optimization.</p>



<a name="191360117"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/191360117" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#191360117">(Mar 21 2020 at 18:38)</a>:</h4>
<p>I still think that it's simpler if we just special-case ZSTs in <code>Vec</code>.</p>



<a name="191360129"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/191360129" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#191360129">(Mar 21 2020 at 18:38)</a>:</h4>
<p>Just stick a few <code>if mem::size_of::&lt;T&gt;() == 0 {...}</code> in a few places and be done with it.</p>



<a name="191373925"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/191373925" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#191373925">(Mar 22 2020 at 01:21)</a>:</h4>
<p>Those changes are not related to <code>Vec</code> but to allocating in genrel. using <code>MemoryLayout</code> and <code>MemoryBlock</code> provides a more convenient abstraction to a pointer associated with a size. It's feeling natural to pass the memory block to a function, which changes the block like growing/shrinking. Or moving the block to <code>dealloc</code> to free it.</p>
<p>Regarding <code>(Raw)Vec</code> I don't really care, but I really want to clean up <code>RawVec</code> as there are a lot duplicated fragments currently.</p>



<a name="191401799"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/191401799" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Christopher Durham <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#191401799">(Mar 22 2020 at 15:35)</a>:</h4>
<p>Allocators should deal in <code>(size, align)</code> layouts and "<code>void*</code>" pointers, never types</p>



<a name="191402013"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/191402013" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Christopher Durham <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#191402013">(Mar 22 2020 at 15:39)</a>:</h4>
<p>(I'm in the process of watching <a href="https://youtu.be/LIb3L4vKZ7U" target="_blank" title="https://youtu.be/LIb3L4vKZ7U">this CppCon talk</a> on <code>std::allocator</code>)</p>
<div class="youtube-video message_inline_image"><a data-id="LIb3L4vKZ7U" href="https://youtu.be/LIb3L4vKZ7U" target="_blank" title="https://youtu.be/LIb3L4vKZ7U"><img src="https://i.ytimg.com/vi/LIb3L4vKZ7U/default.jpg"></a></div>



<a name="191402161"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/191402161" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Christopher Durham <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#191402161">(Mar 22 2020 at 15:42)</a>:</h4>
<p>That said, dealing in a <code>MemoryBlock</code> type that's the pointer and its layout tied together also makes sense.</p>



<a name="191402174"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/191402174" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Christopher Durham <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#191402174">(Mar 22 2020 at 15:42)</a>:</h4>
<p>(Alexandrescu's <code>Blk</code>)</p>



<a name="191402239"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/191402239" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Christopher Durham <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#191402239">(Mar 22 2020 at 15:44)</a>:</h4>
<p>We need to be careful in speccing, though, as <code>Box&lt;T&gt;</code> means that standard sized allocations _will_ be freed with their "used" size, and without indicating excess</p>



<a name="191402332"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/191402332" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Christopher Durham <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#191402332">(Mar 22 2020 at 15:46)</a>:</h4>
<p>That's just telling the allocator that if it indicates excess it has to handle the allocation being talked about with any size in the <code>[requested, requested+excess]</code> range, ofc</p>



<a name="191402358"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/191402358" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Christopher Durham <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#191402358">(Mar 22 2020 at 15:47)</a>:</h4>
<p>One interesting note worth highlighting from the talk is that "[good] [general] allocators are compositions of smaller, more specialized allocators" (paraphrased).</p>



<a name="191402446"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/191402446" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#191402446">(Mar 22 2020 at 15:49)</a>:</h4>
<p>That makes sense, I would imagine the final version of bumpalo would take an allocator parameter to specify where it gets its memory from.</p>



<a name="191402537"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/191402537" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Christopher Durham <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#191402537">(Mar 22 2020 at 15:51)</a>:</h4>
<p>But it also brings up the question of those specialized allocators, and I'm starting to think it's not possible to provide an "ideal" allocator API for both the "bump allocate in a stack array" simple case and the "choose between several different size class allocators" complex case</p>



<a name="191402581"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/191402581" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Christopher Durham <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#191402581">(Mar 22 2020 at 15:52)</a>:</h4>
<p>The former bakes in too many assumptions to be generally useful in a generalized API</p>



<a name="191402585"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/191402585" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Christopher Durham <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#191402585">(Mar 22 2020 at 15:52)</a>:</h4>
<p>But I don't really know</p>



<a name="191402823"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/191402823" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#191402823">(Mar 22 2020 at 15:59)</a>:</h4>
<p>I'll watch the video and get back to you on that.</p>



<a name="191403085"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/191403085" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#191403085">(Mar 22 2020 at 16:05)</a>:</h4>
<p><span class="user-mention" data-user-id="132829">@Christopher Durham</span> You may be interested in reading this about composing allocators: <a href="https://plasma.cs.umass.edu/emery/heap-layers.html" target="_blank" title="https://plasma.cs.umass.edu/emery/heap-layers.html">https://plasma.cs.umass.edu/emery/heap-layers.html</a></p>



<a name="191404166"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/191404166" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#191404166">(Mar 22 2020 at 16:32)</a>:</h4>
<p><span class="user-mention" data-user-id="132829">@Christopher Durham</span> I just watched the video. It turns out that <code>owns()</code> is actually a lot harder to implement in practice, and the lack of it in existing allocators make it impossible to wrap them with the allocator API. See also discussion in <a href="https://github.com/rust-lang/rust/issues/44302" target="_blank" title="https://github.com/rust-lang/rust/issues/44302">#44302</a>.</p>



<a name="191406409"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/191406409" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> HeroicKatora <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#191406409">(Mar 22 2020 at 17:22)</a>:</h4>
<p>If an allocator would be allowed to tag its allocation with custom state, and that state must be provided for calls to realloc, dealloc, etc. then many problems of <code>owns ()</code> would be solved. For example, the tag might encode which underlying allocator has been used instead of the allocator having to reconstruct that information in non-constant time from the pointer itself (and the required <code>Layout</code> might be considered similar such a tag). If that tag is an associated type of the allocator, then it allows constructing a wrapper that hides the tag of an underlying wrapper and always uses <code>()</code> as the tag. This could be done by allocating enough space for the requested layout and the underlying tag then storing the tag into the allocation, potentially requiring that the tag be <code>Copy</code>.<br>
This solution is much harder in C++'s semantics: There is no <code>Copy</code> trait, the tag would be required to implement a move constructor and we'd require a placement-new into the allocation and additionally, I think, the extra space messes with semantics of the placement of the originally requested object. On top of that comes moving the tag out before deallocating, etc..</p>



<a name="191407276"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/191407276" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#191407276">(Mar 22 2020 at 17:43)</a>:</h4>
<p>Or the allocator could just store this tag next to the allocation. I don't see much advantage if the tag needs to be carried around with the object anyways.</p>



<a name="191408108"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/191408108" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> HeroicKatora <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#191408108">(Mar 22 2020 at 18:01)</a>:</h4>
<p>Storing the tag next to the allocation would be precisely what the wrapper does. Enforcing that allocators do all of that themselves is like wrapping ever allocator, which is not zero-cost for nested allocators. Also, why not separate those layers into reusable components if you can to reduce implementation overhead?</p>



<a name="191421926"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/191421926" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#191421926">(Mar 22 2020 at 23:26)</a>:</h4>
<p><span class="user-mention silent" data-user-id="132829">Christopher Durham</span> <a href="#narrow/stream/197181-t-libs.2Fwg-allocators/topic/Next.20steps.3F/near/191402161" title="#narrow/stream/197181-t-libs.2Fwg-allocators/topic/Next.20steps.3F/near/191402161">said</a>:</p>
<blockquote>
<p>That said, dealing in a <code>MemoryBlock</code> type that's the pointer and its layout tied together also makes sense.</p>
</blockquote>
<p>I don't know if we want to store <code>Layout</code> or just the size as <code>Layout</code> is twice as large and the alignment will never change. We have to pass the alignment to other functions then however.</p>
<p><span class="user-mention silent" data-user-id="143274">Amanieu</span> <a href="#narrow/stream/197181-t-libs.2Fwg-allocators/topic/Next.20steps.3F/near/191407276" title="#narrow/stream/197181-t-libs.2Fwg-allocators/topic/Next.20steps.3F/near/191407276">said</a>:</p>
<blockquote>
<p>Or the allocator could just store this tag next to the allocation. I don't see much advantage if the tag needs to be carried around with the object anyways.</p>
</blockquote>
<p>I don't think I like to store the tag next to the allocation. If we decide to use something like <code>MemoryBlock</code> this could also be a trait instead and use an associated type in <code>AllocRef</code>. The tag could then be stored in the implementation of <code>MemoryBlock</code> together with the pointer and the size.</p>



<a name="191424469"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/191424469" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#191424469">(Mar 23 2020 at 00:45)</a>:</h4>
<p>In comparison to C++, <code>owns</code> can also be provided in another trait (<code>OwnedAlloc</code>?). Composing different allocators can rely on this trait then.</p>



<a name="191527445"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/191527445" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#191527445">(Mar 23 2020 at 19:54)</a>:</h4>
<p>As <code>owns</code> cannot be a trait method on <code>AllocRef</code> (This was discussed when the allocator API was introduced the first time), we don't have to bother about this anyway. Composable allocators should live in an external crate on <a href="https://crates.io" target="_blank" title="https://crates.io">https://crates.io</a>.</p>



<a name="191527895"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/191527895" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#191527895">(Mar 23 2020 at 19:57)</a>:</h4>
<p><a href="https://github.com/rust-lang/rust/issues/49668" target="_blank" title="https://github.com/rust-lang/rust/issues/49668">#49668</a>: </p>
<blockquote>
<p><del><code>GlobalAlloc::owns</code>: <a href="https://github.com/rust-lang/rust/issues/44302" target="_blank" title="https://github.com/rust-lang/rust/issues/44302"><a href="https://github.com/rust-lang/rust/issues/44302" target="_blank" title="https://github.com/rust-lang/rust/issues/44302">#44302</a></a> proposes making it required for allocators to be able to tell if it “owns” a given pointer.</del> Not to be required by this trait since glibc and Windows do not support this.</p>
</blockquote>



<a name="191528288"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/191528288" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> HeroicKatora <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#191528288">(Mar 23 2020 at 20:00)</a>:</h4>
<blockquote>
<p>Composable allocators should live in an external crate on <a href="https://crates.io" target="_blank" title="https://crates.io">https://crates.io</a>.</p>
</blockquote>
<p>Totally agree, would it be suitable still to seek input from the working group here?</p>



<a name="191528403"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/191528403" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#191528403">(Mar 23 2020 at 20:01)</a>:</h4>
<p>I just had started writing a crate :)<br>
I think we may link the crate from the WG, but issues should go to the crate's repository.</p>



<a name="191757942"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/191757942" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#191757942">(Mar 25 2020 at 14:59)</a>:</h4>
<p><span class="user-mention" data-user-id="216785">@Tim Diekmann</span> Could you push any updates to the PR as separate commits instead of force-pushing? It makes reviewing easier. We can always squash later before merging.</p>



<a name="192137950"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/192137950" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#192137950">(Mar 28 2020 at 19:25)</a>:</h4>
<p><span class="user-mention" data-user-id="216785">@Tim Diekmann</span> What was the rationale for removing the methods on <code>MemoryBlock</code>?</p>



<a name="192138288"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/192138288" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#192138288">(Mar 28 2020 at 19:36)</a>:</h4>
<p>In my first attempt to implement <code>MemoryBlock</code> it contained <code>Unique</code> instead of <code>NonNull</code>. That required an unsafe <code>new</code> method and a conversion from <code>Unique</code> to <code>NonNull</code> in <code>MemoryBlock::ptr</code>. As we now have <code>MemoryBlock</code> containing <code>NonNull</code> there was no point to make the fields private, so I made them <code>pub</code>. Also there was <code>Layout</code> instead of <code>size: usize</code> and two methods were only shorthands to <code>layout.size()</code> and <code>layout.align()</code>. The remaining methods were just forwarding to the fields, I don't see a reason to keep them, when direct access is possible.</p>



<a name="192410025"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/192410025" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#192410025">(Mar 31 2020 at 15:59)</a>:</h4>
<p><span class="user-mention" data-user-id="143274">@Amanieu</span> Do you wait for another reply of <strong>wg-compiler-performance</strong> or do we want to merge the PR?</p>



<a name="192410084"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/192410084" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#192410084">(Mar 31 2020 at 15:59)</a>:</h4>
<p>I'm tending towards just merging it and dealing with the fallout later.</p>



<a name="192410115"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/192410115" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#192410115">(Mar 31 2020 at 15:59)</a>:</h4>
<p>I presume you don't have any other changes you'd like to make to the PR at the moment?</p>



<a name="192410315"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/192410315" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#192410315">(Mar 31 2020 at 16:00)</a>:</h4>
<p>No, I think the PR is self-contained. Everything else should be in a different PR. The PR is already too big.</p>



<a name="192410557"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/192410557" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#192410557">(Mar 31 2020 at 16:02)</a>:</h4>
<p>Thank you!</p>



<a name="192410982"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/192410982" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#192410982">(Mar 31 2020 at 16:04)</a>:</h4>
<p>So, what's left on the TODO list?</p>



<a name="192411190"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/192411190" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#192411190">(Mar 31 2020 at 16:06)</a>:</h4>
<p><a href="https://github.com/rust-lang/rust/issues/43" title="https://github.com/rust-lang/rust/issues/43">#43</a>: Implement AllocRef on System without GlobalAlloc<br>
<a href="https://github.com/rust-lang/rust/issues/21" title="https://github.com/rust-lang/rust/issues/21">#21</a>: Coherent design of GlobalAlloc and Alloc<br>
<a href="https://github.com/rust-lang/rust/issues/47" title="https://github.com/rust-lang/rust/issues/47">#47</a>: Allocation promises with global AllocRef allocator</p>



<a name="192411246"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/192411246" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#192411246">(Mar 31 2020 at 16:06)</a>:</h4>
<p>Basically these are all related to the global allocator.</p>



<a name="192412526"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/192412526" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#192412526">(Mar 31 2020 at 16:15)</a>:</h4>
<p>Yes. I think we need <a href="https://github.com/rust-lang/rust/issues/43" title="https://github.com/rust-lang/rust/issues/43">#43</a> before we can dive into more <code>GlobalAlloc</code> things</p>



<a name="192440655"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/192440655" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#192440655">(Mar 31 2020 at 19:49)</a>:</h4>
<p>Oh, the PR got a higher priority :)</p>



<a name="192484984"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/192484984" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Christopher Durham <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#192484984">(Apr 01 2020 at 05:30)</a>:</h4>
<p>PR failed on on Linux dist-i586-gnu-i586-i686-musl; it looks like the failing tests are testing that a try_reserve for <code>isize::MAX + 1</code> elements is failing, and it didn't.</p>



<a name="192496979"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/192496979" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#192496979">(Apr 01 2020 at 08:30)</a>:</h4>
<p>Thanks for pointing that out, this made the fix trivial!</p>



<a name="192497073"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Next%20steps%3F/near/192497073" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Next.20steps.3F.html#192497073">(Apr 01 2020 at 08:31)</a>:</h4>
<p>I simply forgot this line, but this is what tests are for, right? :)</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>